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Abstract 


In  today’s  world,  connectivity  is  increasingly  taken  for  granted.  Wireless  networks,  cell  towers,  and  satellites  provide 
ubiquitous  connectivity  through  a  number  of  devices.  However,  in  austere  locations  constant  connectivity  cannot  be 
assumed,  e.g.,  due  to  the  remoteness  of  the  area,  due  to  a  disaster  or  combat  situation,  or  due  to  insecurity  or  lack  of 
access  to  available  communications.  This  paper  describes  a  system,  Marti,  which  the  authors  have  been  developing 
and  demonstrating  that  can  provide  inter-connectivity  and  access  to  information  in  austere  locations.  Marti  is  rapidly 
deployable  and  interoperates  with  a  large  number  of  existing  devices  and  client  applications. 
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1.  Introduction 

Ubiquitous  and  constant  connectivity  is  becoming  increasingly  prevalent  and,  in  many  cases,  assumed. 
The  increasing  availability  of  wireless  infrastructure  in  many  locations,  including  mobile  hotspots,  cell 
towers,  and  satellite  communications  has  made  constant  connectivity  assumed  through  an  increasing 
number  of  devices,  including  handhelds  (e.g.,  mobile  phones),  tablets,  and  even  the  radios  utilized  by 
emergency  and  military  personnel. 

However,  there  are,  and  always  will  be,  austere  locations  in  which  ubiquitous  and  constant  connec¬ 
tivity  cannot  be  assumed  and,  in  fact,  is  unlikely  to  be  available.  The  austerity  and  lack  of  connectivity 
can  be  due  to  the  following: 
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Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 
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•  The  remoteness  of  the  location,  in  which  there  are  no  cell  towers  or  access  points,  or  they  are  too  dis¬ 
tant  to  be  reached  reliably. 

•  Natural  disasters  or  human  activity  (such  as  war)  that  can  destroy  or  overload  the  existing  communica¬ 
tion  infrastructure. 

•  Natural  phenomenon,  such  as  weather  or  terrain,  which  can  interfere  with  the  availability  or  reliability 
of  communications. 

Even  in  situations  in  which  communication  infra¬ 
structure  exists,  constant  connectivity  can  be  missing. 

For  example,  there  might  be  cell  towers,  but  they 
aren’t  accessible  (e.g.,  different  service  provider),  are 
incompatible  (e.g.,  GSM  vs.  CDMA),  or  are  insecure 
for  one’s  purposes.  There  might  be  satellite  communi¬ 
cations,  but  its  access  might  be  restricted,  it  might  need 
to  be  reserved  well  in  advance,  or  it  might  be  highly 
contended.  In  other  situations,  such  as  emergency  re¬ 
sponse  or  tactical  operations,  radios  might  be  com¬ 
monplace,  but  they  might  not  interoperate. 

We  have  been  researching  and  prototyping  Marti, 
an  information  management  system  (IMS)  that  can  be 
used  to  provide  or  augment  connectivity  in  austere 
locations.  Marti  provides  a  publish-subscribe  infor¬ 
mation  broker  that  can  be  hosted  and  rapidly  deployed 
on  manned  or  unmanned  aircraft  or  on  high  altitude 
balloons,  as  shown  in  Figure  1.  At  high  altitudes,  Marti  provides  beyond  line-of-sight  information  broker¬ 
ing  for  tactical  users,  through  standardized  information  formats  and  interfaces,  utilizing  existing  applica¬ 
tions  and  devices,  including  Android-based  devices  and  a  variety  of  tactical  radios.  Because  it  is  based  on 
a  publish-subscribe  model,  users  can  connect  dynamically  and  register  subscriptions  for  future  infor¬ 
mation  that  might  become  available  or  query  for  archived  information.  Information  discovery  and  client 
connection  is  simple  and  dynamic.  Marti  utilizes  standards-based  information  formats,  a  Web  Services 
interface,  and  adapters  to  work  with  existing  application  interfaces. 

The  rest  of  this  paper  describes  the  Marti  IMS,  how  it  provides  connectivity  in  austere  locations,  the 
experiments  and  demonstrations  we  have  conducted  with  Marti,  and  related  work. 

2.  The  Marti  Information  Management  System 

The  goal  of  the  Marti  IMS  is  to  increase  the  situation  awareness  (SA)  of  tactical  users  by  supplying 
ubiquitous  access  to  information.  When  the  fixed  infrastructure  that  we  take  for  granted  is  not  present, 
fails,  or  is  inaccessible  (due  to  security  or  ownership  concerns),  information  access  by  tactical  users  re¬ 
quires  that  they  can  establish  line-of-sight  (LOS)  connectivity  (through  their  tactical  radios)  to  something 
that  can  provide  beyond  line-of-sight  (BLOS)  reachback  to  remote  information  sources  and  networks.  By 
providing  a  rapidly  deployable,  scalable,  and  interoperable  IMS  platform,  Marti  provides  users  in  austere 
locations  with  access  to  real-time  and  on-demand  information.  The  remainder  of  this  section  explains  how 
Marti  is  designed  to  support  ambient  information  access  through  its  modular  architecture,  service  discov¬ 
ery  mechanisms,  intent  to  maintain  interoperability,  and  bandwidth  management  utilities. 

2.1.  The  Marti  Architecture 


(a)  Marti  deployed  on  a 
balloon  at  65K-100K  feet. 


(b)  An  F-16  with  a 
LITEning  pod. 


(c)  The  Scan  Eagle  UAV. 


Figure  1.  Marti  has  been  deployed  on  a  high  altitude 
balloon,  a  pod  attached  to  a  manned  aircraft,  and  un¬ 
manned  aircraft,  including  the  Scan  Eagle. 


The  Marti  IMS  is  designed  as  a  modular,  service-based  publish-subscribe-query  (PSQ)  system.  PSQ  is 
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a  design  paradigm  that  decouples  information  pro¬ 
ducers  (publishers)  from  information  consumers 
(subscribers  and  querying  clients).  Consumers  re¬ 
quest  information  that  is  of  use  to  them  and  might 
become  available  in  the  future  by  registering  inter¬ 
est  in  (i.e.,  subscribing  to)  information  based  on  its 
type  and  indexable  characteristics  (i.e.,  metadata), 
regardless  of  when  it  becomes  available  and  its 
source.  Information  that  has  been  collected  in  the 
past  is  available  through  a  query  interface.  PSQ 
provides  access  to  real-time  information,  i.e.,  sub¬ 
scribers  receive  the  information  they  desire  as  soon 
as  it  is  collected3,  and  to  archived  information. 

Maintaining  modularity  in  the  Marti  architecture 
enables  extensibility  as  new  features  and  services 
become  available  [5].  Marti’s  core  services  (shown 
in  Figure  2)  include  the  Submission  Service,  the 
Information  Brokering  Service,  Query  Service, 

Web  Service,  and  Dissemination  Service,  which 
provide  the  following  functionality: 

•  The  Submission  Service  accepts  published  mes¬ 
sages,  archives  them,  and  forwards  them  to  the 
Query  or  Information  Brokering  Service.  The 
submission  service  also  performs  traffic  shaping  when  applicable. 

•  The  Query  Service  provides  users  with  on-demand  access  to  past  information  by  extracting  and  filter¬ 
ing  information  from  the  archive  (Disk  Storage). 

•  The  Information  Brokering  Service  (Info  Broker)  manages  the  subscriptions  (i.e.,  which  subscribers 
are  subscribed  to  what  information  types)  and  guides  information  dissemination  (i.e.,  to  which  sub¬ 
scribers  should  each  information  object  be  sent). 

•  The  Web  Service  provides  an  HTTP  request/response  interface  for  viewing  archived  information  and 
manipulating  the  behavior  of  the  system  (e.g.,  system  configuration). 

•  The  Dissemination  Service  controls  the  information  that  is  transmitted  to  each  subscriber.  Furthermore, 
the  dissemination  service  implements  a  variety  of  Quality  of  Service  (QoS)  management  techniques  to 
effectively  utilize  limited  communication  channels. 

2.2.  Network  Formation,  Scalability,  and  Discovery 

For  Marti  to  be  an  ambient  system,  it  must  provide  readily  accessible  connectivity  and  transparent  ac¬ 
cess  to  information.  Marti  provides  these  by  being  quickly  deployable,  handling  dynamic  numbers  of  us¬ 
ers  that  come  and  go,  supporting  discovery  of  new  platforms  and  users,  and  reaching  back  through  con¬ 
nections  to  other,  more  fixed  infrastructure. 

Marti  is  designed  to  be  quickly  deployed  in  austere  locations,  either  onboard  airborne  platforms  or  in  a 
centralized  location  on  the  ground.  Once  deployed,  Marti  utilizes  pub-sub  and  service  discovery  as  ways 
of  reducing  the  configuration  burden  on  clients.  The  pub-sub  paradigm  allows  subscribers  to  register  their 


Figure  2.  Data-flow  through  the  high-level  components  of 
the  Marti  architecture. 


a  In  reality,  there  is  some  latency  between  the  time  of  collection  and  the  time  of  subscriber  receipt,  however  the  authors  go  to 
great  lengths  to  minimize  that  latency. 
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interest  in  certain  information  without  the  knowledge  of  which  publishers  have  that  information. 

Platform  and  information  discovery  greatly  simplify  the  client  configuration  -  allowing  clients  to  gath¬ 
er  connection  criteria  about  the  IMS  at  runtime.  Information  discovery  is  automatic;  a  client  registers  a 
subscription  and  if  and  when  information  matching  the  subscription  is  published,  it  is  disseminated  to  the 
client.  However,  if  multiple  subscribers  match  a  published  message,  then  multiple  copies  of  the  message 
will  be  sent.  In  a  severely  bandwidth-limited  broadcast  environment  -  in  which  Marti  is  commonly  de¬ 
ployed  -  this  wastes  bandwidth.  Furthermore,  it  provides  no  support  for  clients  to  discover  the  types  of 
information  that  are  available  for  them  to  request. 

To  facilitate  publish-subscribe  over  the  broadcast  medium,  Marti  utilizes  IP  multicast  and  an  existing 
capability  for  service  discovery.  As  shown  in  Figure  3,  each  client  joins  a  well-known  registry’  multicast 
group.  The  Marti  information  broker  periodically  beacons  (i.e.,  sends  to  the  multicast  group)  a  list  of  in¬ 
formation  types  and  multicast  groups.  Each  client  receives  the  beacon  (because  it  belongs  to  the  registry’ 
group),  chooses  which  types  of  messages  it  wants  to  receive,  and  joins  the  multicast  groups  for  those  in¬ 
formation  types.  When  a  message  is  published,  the  Marti  dissemination  service  sends  it  to  the  multicast 
group  associated  with  the  message  type  which  delivers  it  to  all  the  subscribers  in  the  group. 

There  are  several  limitations  to  this  approach.  First,  subscriptions  registered  in  the  IMS  and  multicast 
groups  are  redundant.  That  is,  to  “subscribe”  to  messages,  the  subscribing  client  can  examine  the  beacon 
and  join  the  proper  multicast  group  or  the  subscriber  can  register  a  subscription  that  matches  the  pub¬ 
lished  information  (which  then  disseminates  the  message  directly  to  the  subscriber).  The  former  is  more 
appropriate  in  a  broadcast  environment  (the  dominant  environment  for  Marti)  in  which  there  are  many 
subscribers  to  each  message.  The  latter  is  more  appropriate  in  a  point-to-point  environment  or  an  envi¬ 
ronment  in  which  there  is  one  subscriber  to  each  message. 

Another  limitation  is  that  the  Marti  broker  has  no  visibility  into  which  clients  (if  any  at  all)  have  joined 
the  multicast  group  for  a  message.  Thus  bandwidth  can  be  wasted  by  (1)  sending  messages  to  empty  mul¬ 
ticast  groups;  (2)  sending  multiple  copies  of  messages  to  individual  subscribers;  and  (3)  continuous  bea¬ 
coning.  This  lack  of  visibility  into  whether  (and  how  many)  clients  are  in  a  multicast  group  also  limits  the 
ability  to  prioritize  messages  when  bandwidth  is  limited  (and  bandwidth  is  always  limited)  because  the 
Marti  broker  cannot  determine  which  messages  are  needed  by  important  clients  and  operations. 

Point-to-point  subscriptions  have  issues  as  well.  A  particular  problem  manifests  itself  in  intermittent 
environments:  the  protocol  that  Marti  uses  to  send  events  to  subscribers  connects  to  subscribers  when 
there  is  an  event  to  send  (we  have  no  control  over  the  particulars  of  this  protocol).  From  a  subscriber’s 
point  of  view,  it  is  not  possible  (without  out-of-band  monitoring)  to  tell  the  difference  between  a  situation 
in  which  it  is  disconnected  from  Marti  and  one  in  which  there  just  are  not  any  matches  to  the  subscription. 
Worse,  if  a  client  is  discon¬ 
nected  for  a  long  time  and 
Marti  fails  to  send  an  event  a 
certain  number  of  times,  Marti 
needs  to  disable  the  subscrip¬ 
tion.  Once  the  client  comes 
back  on  line,  there  is  currently 
no  way  to  know  (again,  with¬ 
out  using  out-of-band  monitor¬ 
ing)  that  the  server  has  disa¬ 
bled  the  subscription.  These 
problems  are  certainly  not  in¬ 
surmountable,  but  solving 
them  in  the  existing  architec¬ 
ture  would  add  complexity.  Figure  3.  Marti's  support  for  information  discovery. 


Send  msg 
via  multicast 
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We  are  developing  an  alter¬ 
native  discovery  technique  that 
combines  the  active  subscrip¬ 
tion  matching  with  midticast 
groups,  enables  better  man¬ 
agement  of  limited  bandwidth, 
is  robust  in  intermittent  net¬ 
works,  and  supports  scaling  to 
multiple  Marti  servers.  As 
shown  in  Figure  4,  in  this  al¬ 
ternative  technique,  instead  of 
the  Marti  server  beaconing  its 
information  types,  each  sub¬ 
scribing  client  periodically 
beacons  its  subscription  predi¬ 
cate  to  the  special  (registry) 
multicast  group.  The  Marti 
broker  is  a  member  of  that 
multicast  group  and  constructs  a  fdter  consisting  of  “or”s  of  the  full  set  of  predicates.  Subscription  match¬ 
es  are  sent  to  a  second  multicast  group  that  all  the  subscribing  clients  have  joined.  The  Marti  broker  filters 
published  messages  and  disseminates  them  to  the  subscriber  midticast  group  only  if  they  pass  the  fdter, 
i.e.,  they  match  at  least  one  subscription. 

This  technique  has  advantages  in  severely  bandwidth  limited  environments,  including  the  following: 


Automatic  discovery  of  new¬ 
ly  available  information  types 

A  client  does  not  need  to  monitor  the  service  beacons  and  explicitly  join 
the  multicast  group  for  a  new  information  type. 

Potentially  significant  savings 
in  bandwidth 

Messages  are  only  sent  if  there  is  some  subscriber  that  wants  them  and 
each  is  sent  once  no  matter  how  many  subscribers  want  the  message. 

Message  prioritization 

Prioritization  of  messages  across  publishers,  types,  and  subscribers. 

Facilitate  support  for  multiple 
Marti  servers 

A  new  server  receives  the  beacon  of  subscriptions  and  filters  messages 
published  to  it  using  the  subscriptions.  Subscribing  clients  automatically 
receive  matching  messages  from  the  new  server  without  having  to  ex¬ 
plicitly  register  with  it. 

The  main  drawback  of  this  technique  is  that  subscribers  can  receive  messages  in  which  they  have  no 
interest.  This  is  analogous  to  the  current  state  of  existing  broadcast  media,  in  which  everyone  in  broadcast 
range  can  receive  transmissions.  Client  side  fdtering  of  messages  can  remedy  this  situation. 


2.3.  Interoperability 

Another  challenge  Marti  faces  in  providing  ambient  functionality  in  austere  locations  is  interoperabil¬ 
ity.  For  the  information  system  to  be  truly  invisible  to  its  human  users,  it  should  support  the  users’  current 
tools  and  workflows.  It  is  important  that  Marti  not  require  additional  or  different  equipment  than  that  al¬ 
ready  carried  by  tactical  users.  Marti  accomplishes  interoperability  by  supporting  information  types 
commonly  used  by  existing  tactical  systems,  including  the  XML-based  Cursor  on  Target  (CoT)  type  used 
by  many  military  users  [14]  and  multiple  video  formats,  including  FI. 264  and  Key-Length-Value  (KLV). 
CoT  is  an  extensible  XML-based  specification  that  can  be  transmitted  by  nearly  any  IP-interface-enabled 
client  over  TCP  or  UDP  (including  multicast).  CoT’s  low  barrier  to  entry  creates  a  large  user-base  for 
new  clients.  Marti  already  integrates  with  several  existing  client  applications  that  run  on  military  grade 


Figure  4.  An  alternative  discovery  technique  supporting  bandwidth  constrained  ambi¬ 
ent  environments. 
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equipment.  Android  tablets,  and  handhelds.  Thin  wrappers  trivially  translate  messages  from  legacy  appli¬ 
cations  into  CoT  (and  vice  versa).  Also,  Marti’s  web  services  allow  any  HTTP-enabled  client  to  view 
archived  information.  By  supporting  users’  current  tools  and  workflows  and  fostering  a  large  user-base 
for  client  applications,  the  Marti  IMS  is  an  interoperable  communication  substrate  that  remains  invisible 
to  its  human  users. 

2.4.  Effective  Bandwidth  Usage 

Effective  bandwidth  usage  is  critical  to  providing  ambient  information  access  to  austere  areas  with  a 
highly-constrained  communication  medium.  Marti  employs  several  QoS  techniques  for  managing  band¬ 
width.  First,  dissemination  bandwidth  is  rate-controlled  per-client  to  prevent  the  system  from  overloading 
the  bandwidth  to  any  individual  client.  Maintaining  queues  of  outgoing  information  messages  also  allows 
for  other  latency-decreasing  operations.  For  example,  stale  information  in  a  dissemination  queue  can  be 
replaced  by  newer  information  of  the  same  typeb.  Also,  maintaining  dissemination  queues  allows  prioriti¬ 
zation  for  differentiated  services  (DiffServ)  [8],  Further  research  [2]  shows  promise  for  passively  moni¬ 
toring  and  automatically  configuring  the  bandwidth  to  subscribers  with  highly-dynamic  network  connec¬ 
tions.  Second,  traffic  shaping  is  employed  in  Marti,  for  example,  to  reduce  the  size  and  resolution  of  an 
extraneously  large  image.  Finally,  in  situations  where  the  network  is  naturally  a  broadcast  medium,  mul¬ 
ticast  is  used  to  prevent  multiple  copies  of  the  same  message  from  being  transmitted  point-to-point  to 
different  subscribers.  Effectively  managing  the  utilization  of  bandwidth  in  Marti  increases  the  number  of 
users  that  can  participate  in  using  the  ambient  system. 

2.5.  The  Marti  Prototype 

The  Marti  IMS  is  built  using  a  lightweight  tactical  version  of  Phoenix,  a  pub-sub  service-based  system 
developed  by  the  US  Air  Force  [6],  Marti  has  been  hosted  on  a  variety  of  platforms,  including  high- 
altitude  (up  to  85,000  feet)  unmanned  balloons,  sensor  pods  (e.g.,  LITEning  Pod  [10])  attached  to  manned 
and  unmanned  aircraft,  and  on  unmanned  aerial  systems  including  the  Scan  Eagle. 

3.  Experiments  and  Evaluations 

Marti  has  been  used  in  a  variety  of  field  demonstrations,  often  involving  several  airborne  assets.  These 
demonstrations  provided  a  wide  range  of  scenarios,  with  varying  numbers  and  types  of  clients  and  infor¬ 
mation  and  including  scenarios  that  are  very  bandwidth-limited  and  others  that  are  CPU-bound. 

The  first  set  of  field  demonstrations  hosted  Marti  on  PC/ 104  boards  on  a  high-altitude  balloon  to  pro¬ 
vide  information  management  for  beyond-line-of-sight  communication  between  multiple  ground  users. 
These  balloons  flew  at  near-space  altitudes  (with  no  tether),  and  used  a  low-throughput  IP  radio  that  pro¬ 
vided  on  the  order  of  tens  of  kB/s  of  bandwidth.  The  very  low  bandwidth  and  lack  of  positive  control  over 
the  airborne  platform  made  for  difficult  experimentation.  In  particular,  intermittent  connectivity  was  a 
constant  problem.  Another  problem  unrelated  to  software  and  connectivity  was  overheating.  The  comput¬ 
er  on  which  Marti  ran  needed  to  be  in  a  sealed  container  to  protect  against  moisture,  and  once  at  altitude 
the  ambient  temperature  was  cold  enough  to  keep  the  board  cool  via  convection.  However,  during  ascent 
we  observed  overheating  problems. 

Marti  has  been  flown  on  the  payload  board  on  Group  2  unmanned  vehicles  (UAVs)  (low  altitude,  long 
endurance)  [12].  These  tests  used  radios  with  much  shorter  range  than  those  we  used  on  the  high-altitude 


b  Because  some  types  of  information  should  not  be  replaced,  a  per-information-object-type  replacement  policy  controls  whether 
or  not  a  type  of  information  should  be  replaced. 
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balloon,  but  much  higher  bandwidth.  Marti  ingested  imagery  being  produced  by  the  sensors  onboard  the 
UAV,  archived  it,  and  distributed  it  in  response  to  subscribers. 

As  a  way  to  improve  throughput  to  bandwidth-constrained  subscribers,  we  added  multicast  capabilities 
to  Marti  as  we  expanded  to  demonstrations  involving  larger  UAVs  and  targeting  pods  [10].  Multicast 
added  some  useful  capability,  such  as  being  able  to  more  efficiently  deliver  identical  data  to  multiple  re¬ 
ceivers.  However,  multicast  introduces  a  host  of  other  issues,  the  most  important  being  inconsistent  sup¬ 
port  by  radios.  Multicast  also  presents  a  challenge  for  managing  QoS  in  publish/subscribe  systems,  be¬ 
cause  multicast  group  membership  is  not  exposed  by  the  IP  layer.  As  a  consequence,  not  only  is  it  diffi¬ 
cult  to  prioritize  based  on  current  users,  but  when  using  radios  that  support  sparse-mode  multicast  it  is 
difficult  to  know  how  much  bandwidth  is  actually  being  used  (data  may  never  be  transmitted  if  there  are 
no  other  members  of  the  multicast  group). 

Within  multicast  groups,  however,  we  implement  prioritization  schemes  based  on  properties  of  the 
publishers  and  information  with  the  option  of  replace-per-publisher  policy  to  enforce  QoS  [5],  This  al¬ 
lows  us  to  control  the  delivery  of  important  information  in  preference  to  less  important  information  and  to 
manage  latency  and  queue  growth  in  the  face  of  overloaded  or  constrained  networks.  Figure  5  shows  the 
performance  of  Marti  in  terms  of  cumulative  number  of  information  objects  lost  while  delivering  imagery 
to  a  multicast  group  over  a  220  kbps  network.  One  of  the  imagery  streams  is  being  collected  from  an  area 
of  interest  (AOI)  and,  hence,  is  higher  importance  than  the  other  streams.  With  only  three  image  streams 
(from  AOI  UAV,  UAV1,  and  UAV2)  the  network  is  not  overloaded  and  no  information  is  lost.  However 
at  time  S  (indicated  by  the  vertical  line  in  the  figures),  a  fourth  UAV  (UAV3)  also  starts  publishing  im¬ 
agery.  The  additional  data  from  the  fourth  UAV  causes  the  publishers  to  overload  the  network,  and  be¬ 
cause  the  producers  are  using  a  best-effort  protocol  (UDP)  the  overload  is  manifested  as  loss  of  infor¬ 
mation.  In  the  baseline  case,  shown  in  Figure  5(a),  with  no  QoS  management,  the  loss  due  to  the  conges¬ 
tion  in  the  network  is  uncontrolled,  and  the  AOI  UAV  feed  (the  most  important  one)  is  unlucky  enough  to 
suffer  significant  loss.  Figure  5(b)  shows  that  with  Marti,  the  most  important  image  stream  (from  AOI 
UAV)  suffers  no  loss,  and  the  other  streams  suffer  more  controlled  loss. 

Likewise,  Figure  6  shows  the  average  latency  and  standard  deviation  of  images  from  each  publisher 
before  and  after  the  network  is  loaded  with  Marti  providing  QoS  management.  In  the  overloaded  situa¬ 
tion,  the  prioritized  stream  ( AOI  UAV)  maintains  low  latency  and  low  jitter  delivery  of  imagery,  while  the 
other  image  streams  are  degraded  consistently  to  make  room  for  the  high  priority  stream. 
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Figure  5.  Information  loss  in  (a)  a  baseline  overload  situation  with  no  QoS  management  and  (b)  with  Marti  QoS  management  in 

which  the  stream  of  AOI  imagery  suffers  no  loss. 


Joseph  Loyall/  Procedia  Computer  Science  00  (2012)  000-000 


With  the  UAV  and  pod  exercises,  the  focus 
of  Marti  shifted  from  providing  a  smart-relay 
(as  in  the  balloon  scenarios)  to  providing  ser¬ 
vices  related  to  on-board  sensor  arrays.  This 
shift  played  into  Marti’ s  advantages  and  focus. 
For  instance,  for  a  variety  of  technical  and  non¬ 
technical  reasons  it  is  difficult  to  put  QoS  man¬ 
agement  into  every  sensor  that  is  producing 
data.  Having  Marti  on  a  LAN  with  the  sensor 
(i.e.,  co-located  on-board  a  UAV  or  pod)  obvi¬ 
ates  the  need  for  QoS  management  for  that  part 
of  the  data  path.  The  part  of  the  data  path  that 
remains  (i.e.,  from  the  IMS  to  clients)  is  fully 
under  Marti ’s  control  (since  Marti  is  the  send¬ 
er),  and  QoS  can  be  implemented  and  enforced 
across  the  full  set  of  clients  without  burdening 
every  client  with  QoS  logic  or  Marti-specific 
protocols. 
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Figure  6.  Average  latency  and  standard  deviation  in  milliseconds  of 
the  image  streams  prior  to,  and  following,  network  overload  with 
Marti  providing  QoS  management. 


4.  Related  Work 


Marti  shares  many  similarities  with  Extensible  Message  and  Presence  Protocol  (XMPP)  servers  (e.g., 
OpenFire,  ejabberd)  [7][13][15]  in  that  they  both  have  the  capability  of  passing  XML-formatted  messages 
between  de-coupled  clients  using  the  Pub-Sub  paradigm.  However,  they  differ  in  that  XMPP  servers  re¬ 
quire  clients  to  establish  and  maintain  a  persistent  connection  to  the  server.  This  requirement  is  driven  by 
the  need  for  XMPP  servers  to  send  information  to  otherwise-unreachable  downstream  clients  (i.e.,  that  are 
potentially  behind  firewalls).  Unfortunately,  this  restriction  causes  XMPP  to  suffer  in  networks  with  in¬ 
termittent  connectivity  because  each  separate  client  shoulders  the  burden  of  maintaining  a  persistent  con¬ 
nection  to  the  server.  Marti,  on  the  other  hand,  excels  in  austere  locations  because  it  does  not  require  its 
clients  to  establish  or  maintain  persistent  connections  to  the  server. 

Several  prominent  pub-sub  systems  have  been  developed  in  recent  years  as  a  means  of  distributing  in¬ 
formation  in  resource  challenged  environments.  Perhaps  most  similar  to  the  presented  work  on  Marti  is 
the  Advanced  Information  Management  Systems  (AIMS)  [3].  AIMS,  like  Marti,  was  designed  with  the 
goal  of  utilizing  airborne  platforms  to  extend  network  range  beyond  line  of  sight  and  provide  publish, 
subscribe  and  query  capabilities  to  users.  While  the  Marti  architecture  supports  integration  with  a  wide 
range  of  clients  through  the  use  of  adapters  to  and  from  the  CoT  specification,  AIMS  limited  its  legacy 
client  to  that  of  the  two  technologies  from  which  it  was  derived,  the  Advanced  Information  Architecture 
(AIA)  and  the  Joint  Battlespace  Infosphere  (JBI). 

The  OMG  Data-Distribution  Service  (DDS)  [11]  is  a  pub-sub  middleware  which  has  seen  widespread 
use  in  recent  years.  DDS  provides  real-time  information  dissemination  based  on  topic  matching  only  and 
a  rich  set  of  QoS  parameters,  but  does  not  support  archival  (beyond  a  limited  history  function).  DDS’s 
discovery  feature  is  performed  through  subscription  to  built-in  topics  (such  as  DCPSTopic  to  get  all  topics 
that  have  been  registered).  QoS  management  across  multiple  client  connections  that  share  bandwidth  re¬ 
quires  application-level  support  (similar  to  what  we  are  doing  in  Marti)  outside  of  DDS. 

Beyond  line  of  sight  communication  is  necessary  for  ambient  computing  in  austere  locations.  Satellite 
links  [1][4]  are  commonly  used  in  such  settings  but  have  several  shortcomings  compared  to  airborne  plat¬ 
forms  such  as  those  utilized  by  Marti.  The  greatest  of  these  issues  is  dynamism  and  ease  of  deployment. 
Launching  a  satellite  into  orbit,  or  even  maneuvering  a  satellite  in  orbit,  requires  a  large  amount  of  re- 
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sources  and  significant  planning.  Such  actions  may  not  be  feasible  on  the  time  scale  necessary  to  deliver 
additional  communication  infrastructure  to  areas  struck  by  disaster  or  facing  a  temporary  rapid  increase  in 
population  (such  as  a  gathering  of  people).  SATCOM  is  frequently  highly  contended,  expensive,  and  in 
some  cases  must  be  reserved  well  in  advance.  The  airborne  platform  approach  taken  by  Marti  requires 
significantly  fewer  resources.  It  has  been  shown  that  the  equipment  necessary  to  field  a  Marti  instance  can 
be  rapidly  attached  to  a  wide  range  of  platforms  including  piloted  aircraft,  UAVs,  and  weather  balloons. 

Mobile  ad-hoc  networks  (MANETs)  [16]  and  Disruption  Tolerant  Networking  (DTN)  [9]  try  to  ad¬ 
dress  some  aspects  of  intermittent  connectivity.  However,  these  technologies  deal  with  layer  3  (IP  rout¬ 
ing)  issues,  not  application-level  concerns.  The  dynamic  nature  of  such  networks  enables  them  to  be  rap¬ 
idly  deployed  in  austere  locations  but  also  introduces  potential  usability  problems.  With  nodes  continu¬ 
ously  entering  and  leaving  a  remote  network  a  user  may  not  be  sure  they  are  accessing  all  relevant  infor¬ 
mation.  Through  a  combination  of  service  discovery  and  PSQ  mechanisms,  Marti  is  in  a  position  to  pro¬ 
vide  MANET  endpoints  with  the  information  they  require. 

5.  Conclusions 

We  have  been  developing  Marti,  an  information  management  system  that  can  provide  ambient  connec¬ 
tivity  and  access  to  information  for  tactical  users  in  austere  locations  where  other  connectivity  is  scarce. 
Marti  contains  a  number  of  advantages  including  that  it  is  rapidly  deployable,  works  with  existing  tactical 
devices  and  pervasive  handhelds  alike,  is  scalable,  and  provides  the  QoS  management  needed  by  critical 
users  such  as  first  responders,  law  enforcement,  or  the  military.  Marti  has  been  evaluated  in  flight  demon¬ 
strations  and  experiments,  with  multiple  tactical  users  and  client  platforms,  and  in  multiple  realistic  sce¬ 
narios.  Marti  shows  promise  for  providing  needed  connectivity  in  locations  and  situations  in  which  fixed, 
accessible,  and  assumed  connectivity  infrastructure  is  not  available. 
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